kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.19971216-19980424/000049_news@newsmaster….columbia.edu _Sun Jan 4 11:09:45 1998.msg

Internet Message Format | 1998-04-22 | 8KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA25317
    for <[e-mail]>; Sun, 4 Jan 1998 11:09:44 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id LAA11052
    for kermit.misc@watsun; Sun, 4 Jan 1998 11:09:44 -0500 (EST)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: [e-mail] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Problem with CKERMIT TRANSMIT
Date: 4 Jan 1998 16:09:36 GMT
Organization: Columbia University
Lines: 161
Message-ID: <68oc80$50p$[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:8217

In article <[e-mail]>,
John A Santos <[e-mail]> wrote:
: In article <[e-mail]>,
: jf mezei <"[non-spam]jfmezei"@videotron.ca> says...
: > John W. Manly wrote:
: > > I've been running into a very frustrating problem with the CKERMIT
: > > TRANSMIT command when used over TCP/IP to a port other than the standard
: > > TELNET port (port 23).
: >
: > > But the TRANSMIT operation never seems to work, though the rest of the
: > > script does work.
:
TRANSMIT just blasts the contents of the file out the communication
connection, more or less.  There are a few adjustments you can make.  Its
operations and the adjustments you can make to them are described in detail
in "Using C-Kermit", 2nd Edition, Chapter 15.

: > Been there, experienced the same thing. I fixed it wth the use of
: > open read file.name
: > :myloop
: > read \%a
: > if fail goto mydone
: > output \%a\%13
: > goto myloop
: >
: > :mydone
: > close read
:
This does just about the same thing that TRANSMIT does, but evidently
slows the process down enough, in this case, to allow the application on the
other end to keep up.  You might just as well have used:

  set transmit pause xxx

where xxx is the number of milliseconds to pause after sending each line.

Also, the loop above does not read back echoes from the other end, so if
the other end is indeed echoing, the echoes might fill up the reverse channel
and eventually block it.

: > Also, what I find most interesting is that sending \13 seems to result
: > in \13\10 being sent !
:
It is being sent.  C-Kermit 6.0 and earlier do this on all TCP connections,
Telnet or not (except Rlogin), by default, since experience shows that most
servers on non-Telnet ports (except Rlogin), even though they might not do
Telnet protocol negotiations, still follow the Telnet NVT specification,
which demands this.  If if causes problems, you can use:

  set telnet newline-mode binary

to force CR to be sent as CR alone.

: > I am on VMS 5.5-2, CKERMIT 6.0.192 6 sep 96   (VAX, of course).
: > TCP stack is CMU-IP.
: >
: We're using C-Kermit to talk to an SMTP server, using both output
: and TRANSMIT commands.  The key (for OUTPUT) is you need to do
: INPUT's to soak up the echoes and responses from the server.  SMTP
: gives numeric response codes for various commands and errors;
: we look for these in the responses to make sure everything is working.
: The data (i.e. mail message) doesn't produce a response, just an echo.
: I think it is the SMTP server that is echoing \13 as \13\10, not
: Kermit sending \13\10.  Anyway, we were sending each line with a \13
: and then waiting for the \13\10 in the response with an INPUT.
:
Right.  SMTP is a protocol that has messages containing function codes.
By the way, these can be handled very nicely in C-Kermit 6.0 and MSK 3.15
with the new MINPUT and SWITCH statements (for an example, see the C-Kermit
TAP alpha paging script).

: If you use TRANSMIT, it should soak up the echoes for you automatically
: but it won't understand the protocol stuff.
:
Right.

: I'm not familiar with NNTP, but SMTP has some specific handshaking that
: you have to do with the server and I think NNTP must be similar.  You need
: to send a HELO hostname command, and wait for the response, to identify
: the sending system.  Then you need to send a FROM: command and a TO:
: command, identifying the sender and receiver's mail addresses, waiting for
: responses in each case.  (I forget the precise order and format of these
: commands...)  Then you need to send a DATA command.  The server replies to
: the data command with a message telling you its okay to start sending, and
: to terminate the message with a line with a single period.  When we get
: this message, we send a text file with the formatted mail message in it,
: using TRANSMIT.  After the transmit, we OUTPUT .\13 and wait for the SMTP
: server to say it got it (with another INPUT.)
:
: There are a couple of gotcha's with SMTP that might apply to NNTP, too.
: SMTP uses a line consisting solely of a period to indicate end-of-
: message, so you have to stuff an extra period at the beginning of
: any line starting with a period to avoid it seeing a false end-of-
: message.  We do this in formatting the mail message file before
: transmitting it.
:
: The second gotcha is really a Kermit issue.  OUTPUT has an escape
: mechanism: \number gets converted to an ASCII character whose value
: is the number (e.g. \13 gets converted to <CR>), and \{special-char}
: gets converted as well, where special-char is any of a list of
: things.  For example, \n becomes a <null>, \\ becomes a single back-
: slash, etc.  We need to suppress the translation to allow these literal
: strings to appear in mail messages (\n wreaks havoc with C programs,
: and all the substitutions occur with annoying frequency in MIME-encoded
: documents.)  There is a work-around for this (can I mention it yet,
: Frank?)...
:
In the following script fragment:

  read \%a
  if fail ...
  output \%a\13

we read a line from a file into the variable \%a.  In the OUTPUT command, we
need to replace the variable by its contents, so we can't (e.g.) turn off
variable expansion entirely with SET COMMAND QUOTING OFF, because then the
OUTPUT command would send "\%a\13" literally.

However if we leave it ON, the variable \%a is evaluated recursively, so
if the line contains any backslashes, the parser "interprets" them.  This is
not a bug, but a design feature (see the boilerplate-letter example in the
manual).

It would seem the solution is to use the *other* kind of variable, the kind
that is evaluated one level only, not recursively:

  read line
  if fail ...
  output \m(line)\13

This works fine provided (as John points out), the line does not contain
the special OUTPUT escapes, \N, \B, or \L for sending NUL and BREAK.

C-Kermit 6.1 (still in development; watch this space for announcements) has
a new command:

  SET OUTPUT SPECIAL-ESCAPES { ON, OFF }

to control this.  If you want to send the lines of a text file literally,
no matter what they contain, in a READ / OUTPUT loop, you can use:

  set output special-escapes off
  open read foo.txt
  if fail stop 1 can't open file
  while 1 {
      read line
      if fail break
      output \m(line)\13
  }

: ... but TRANSMIT doesn't have this problem, and is quite a bit
: faster than a READ-OUTPUT-INPUT loop, so we use TRANSMIT for the body
: of the message.
:
I don't know how NNTP works either, offhand, but if it really just wants
bunch of lines, you should be able to use the TRANSMIT command.  Read about
all the options in the manual, especially SET TRANSMIT PROMPT (wait for echo),
SET TRANSMIT FILL (filler for empty lines), and SET TRANSMIT EOF (what to
send upon end of file).

- Frank